Single Blog

A pesar del borrador de la definición de NIST, National Institute of Standards and Technology, seguimos hablando de Cloud Computing como si fuera la tecnología capaz de hacer de todo.

Una de estas características muy mencionadas es la supuesta escalabilidad innata de la tecnología, así que comencemos primero con una comprensión adecuada de la escalabilidad:

Podemos definirlo como la capacidad de crecimiento de un sistema en función del número de peticiones externas al propio sistema. Generalmente significa crecimiento horizontal, es decir, en «hardware básico», que se resume en la adición de servidores baratos para aumentar la potencia del sistema y equilibrar naturalmente su carga. En realidad, parece encajar con el Cloud Computing, que por definición sería una infraestructura simplemente escalable, basada en «hardware básico» y capaz de entregar energía bajo demanda al usuario final. Muchos de los arquitectos de soluciones recordarán muy bien las complejidades a las que se enfrentan para poder escalar las aplicaciones de los clientes, y también consideramos que la mayoría de los portales y redes sociales más grandes han desarrollado su propia lógica para escalar, lógicas nacidas del tipo de aplicación.

Cuando en el año 2007 nos topamos con los servicios de Amazon AWS, fue mientras leíamos el sitio por excelencia dedicado a la escalabilidad highscalability.com donde se publicó un artículo que hipotetizaba el uso de los servicios web de Amazon para el desarrollo de las redes sociales, entonces aún no se había acuñado el término Cloud Computing. Como ahora se sabe, el Cloud Computing se basa en la virtualización de servidores, almacenamiento y servicios de red, por lo que hasta no hace mucho tiempo los más expertos juzgaban mal el uso de la virtualización ya que las máquinas virtuales individuales no podían tener el mismo rendimiento que una configuración igual sin una capa de hipervisor, incluso hoy en día se pueden encontrar arquitectos contrarios. No es erróneo como objeción, pero el razonamiento que lleva a preferir la Nube al enfoque genérico es el enorme ahorro económico y la simplicidad y rapidez de adquisición de recursos, en comparación con la implementación de nuevo hardware que también involucra personal calificado para las configuraciones. Si luego pensamos que Amazon, el e-commerce más grande del mundo, trabaja con una infraestructura igual a los servicios de AWS que brinda a los clientes, también nos hace reflexionar sobre el rendimiento de una correcta implementación en la Nube. Amazon ha madurado con el tiempo y ha desarrollado internamente cuáles son las lógicas elásticas de la Cloud que vende a los clientes de AWS, como se puede ver en este vídeo donde Jeff Bezos, fundador de Amazon.com describe Amazon Web Services que es un producto nacido de los laboratorios de Amazon para gestionar su infraestructura:

Como es bien sabido, el Cloud Computing puede proporcionar servicios de tres maneras:

1. SaaS
2. Paas
3. IaaS

En el primer caso, SaaS (Software as a Service), hay una aplicación ya desarrollada y, por lo tanto, ya diseñada para escalar en la infraestructura subyacente. En este caso, no es seguro que haya una nube debajo; este es el caso, por ejemplo, de Gmail, Google Documents, SalesForce.

En el segundo caso PaaS (Platform as a service) existe una plataforma capaz de alojar aplicaciones hechas por otros, pero estas aplicaciones deben cumplir con los estrictos requisitos; Este es el caso, por ejemplo, de Google App Engine , que le permite publicar aplicaciones en Java y no preocuparse si el tráfico de estas aplicaciones crece drásticamente. De nuevo, no siempre es cierto que el sustrato sea una nube.

El último es el IaaS (Infrastructure as a services), que representa una serie de interfaces de software (APIs, webservices) que pueden ser utilizadas a través de la autenticación, con las que es posible programar los recursos computacionales que necesitamos para ejecutar nuestra aplicación. Por lo tanto, esta capa no es escalable de forma natural, sino que deberíamos ser capaces de programarla para escalar nuestra aplicación; el ejemplo más claro y conocido de IaaS es AWS (Amazon WebServices).

Soluciones

Muchas empresas están emergiendo y tratando de establecerse en el mercado de la escalabilidad en la nube. Todas estas realidades son software desarrollado en la capa más baja, software capaz más o menos de responder a eventos de sobrecarga equilibrando la carga sobre los nuevos recursos solicitados desde el sistema de forma automática. La mayoría de estos softwares se posicionan entre PaaS e IaaS porque deben permitir un mínimo de programabilidad / configuración al usuario que, por lo tanto, no puede estar familiarizado con el tema; uno de los casos más representativos es el de RightScale, que, sin embargo, además de complejo también es caro.

RightScale crea una capa más sencilla que la programación bruta de comandos de la API de AWS, a través de diversos casos ya desarrollados se puede guiar en la creación de nuestra infraestructura virtual en la Nube, escalable según la lógica que vamos a definir.

Hoy es la versión beta de la (tan esperada por nosotros, como se había anticipado) solución de escalabilidad de AWS. Amazon está lanzando los siguientes servicios web en versión beta hoy:

• CloudWatch
• ElasticLoadBalacing
• Escalado automático

Estos tres servicios que, como es bien sabido, se utilizan a través de scripting, permiten monitorizar AMIs (amazon machine images), programar un balanceador de carga para nuestra aplicación y definir grupos y triggers para intervenir automáticamente nuevos recursos que soporten las demandas de rendimiento de nuestra aplicación.

La oferta parece excelente, solo el CloudWatch parece excesivo en costo, monitorear 10 AMIs costaría más que el costo de una AMI en la que podemos instalar un sistema de monitoreo que pueda monitorear muchas más.

Volviendo al problema de la escalabilidad, por lo tanto, existen soluciones en la nube para garantizarnos un desarrollo sin preocupaciones, pero solo los buenos arquitectos pueden plantear las excepciones adecuadas, ¿cómo escalamos una base de datos?

Escalabilidad de la base de datos

Y es aquí donde podemos decir que el Cloud Computing no permite naturalmente escalar, sino que es necesario adoptar una compleja serie de medidas que deben ser evaluadas caso por caso. A estas alturas ya es sabido por los más expertos que escalar una base de datos relacional de una red social, es decir, con un balance R/W de alrededor del 50%, no es fácil e implica toda una serie de enfoques para distribuir las solicitudes dividiendo la base de datos en muchas partes (sharding), cambios en la aplicación e inserciones de inMemoryDatabase (por ejemplo, memcached) para preservar la memoria de la posición de las piezas.

Los más astutos podrían decir que podríamos pasarnos a las soluciones modernas de inMemoryDataGrid, es decir, una especie de nube de recursos RAM sobre la que esparcimos nuestra base de datos. Bueno, ciertamente el rendimiento sería muy recompensado, pero el costo de un recurso RAM en comparación con el recurso HD es mayor en el mismo orden de magnitud que el de RAM Vs HD de mayor rendimiento, además de ser antieconómico también es sobreabundante ya que no todos los datos de nuestra aplicación es necesario mantenerlos en línea todo el tiempo, porque tal vez no lo haya solicitado nadie.

Otra tendencia muy comercial, pero poco funcional es la Nube privada capaz de escalar a la Nube Pública (Nube Híbrida). En primer lugar, aún no tenemos un estándar, por lo que se debe desarrollar ad hoc para cada cliente, de acuerdo con el problema anterior, si nuestra necesidad es la escalabilidad de la base de datos, ¿cómo la escalamos de Privada a Pública? Teniendo en cuenta que, generalmente, el ancho de banda útil para conectar un CED privado con un centro de datos donde reside una Nube es del orden de decenas de Mbits en descarga y aún menos en carga. Sería necesario activar réplicas que podrían estar fácilmente desincronizadas.

Necesidades reales del cliente

El cliente generalmente requiere simplicidad, requiere pasar a la Nube sin ningún impacto en su normal desarrollo, sin alterar la aplicación, sin abandonar la lógica relacional de su base de datos, porque constituirían grandes costos, incluso reemplazos de personal ya que no están calificados o no son aptos para reescribir la aplicación para crecer en la Nube.

VMEngine está lanzando su primera versión basada en un enfoque simple de escalabilidad, para el escalado automático de toda la aplicación, incluidos los servidores de bases de datos, y mientras tanto está investigando para que la escalabilidad sea cada vez más automatizada y cada vez más transparente para el cliente que puede volver a desarrollar sin tener que alterar el conocimiento de sus desarrolladores